1. Field
This disclosure relates to generation of simulated network traffic for testing a network, network subset, network device or group of devices.
2. Description of the Related Art
In many types of communications networks, each message to be sent is divided into portions of fixed or variable length. Each portion may be referred to as a packet, a cell, a datagram, a data unit, or other unit of information. These portions may be packaged with a headers into frames, and may be split and repackaged during transmission through the network. All of these variations are referred to herein as packets.
Each packet typically contains a portion of an original message, commonly called the payload of the packet. The payload of a packet may contain data, or may contain voice or video information. The payload of a packet may also contain network management and control information. In addition, each packet contains identification and routing information, commonly called a packet header. The packets are sent individually over the network through multiple switches or nodes. The packets are reassembled into the message at a final destination using the information contained in the packet headers, before the message is delivered to a target device or end user. At the receiving end, the reassembled message is passed to the end user in a format compatible with the user's equipment.
Communications networks that transmit messages as packets are called packet switched networks. In order to test a packet switched network or a device included in a communications network, it is often desirable to automatically transmit network traffic having a data rate equal to the line rate or maximum possible data rate of the network communication path or device.
A series of packets originating from a single source and having a specific type of packet and a specific rate will be referred to herein as a “stream.” A source may be, for example, a port on a network interface card. A source may support multiple outgoing streams simultaneously and concurrently, for example to accommodate multiple packet types or rates. “Simultaneously” means “at exactly the same time.” “Concurrently” means “within the same time.”
For the purpose of reporting network traffic data, the packets within a stream may be organized into flows, where a “flow” is any plurality of packets for which network traffic statistics are accumulated and reported. The packets in a given flow may be distinguished by a flow identifier contained in each packet. The flow identifier may be a numeric value that may be based on or derived from, for example, an address, a port number, a tag, or some other field or combination of fields within each data unit; may be user defined; or may be based on meta data about the packet.
A plurality of concurrent streams may be combined to form the output from a traffic generator, which will be referred to herein as “test traffic”. The streams within the test traffic may be combined through interleaving. The interleaving may be balanced, unbalanced, and distributed among the represented streams. The data rate of the test traffic may be equal to the line rate of a network communication path over which the output is transmitted. To test a modern “triple play” network and network equipment, the test traffic may contain simulated email and other data messaging, data, images, audio, and video streams.
Test traffic may be generated in many different ways. According to one prior art process, a user uses a computer to define the test traffic, and then from the same user interface the user initiates the transmission of the defined test traffic. The test traffic is generated by specialized hardware connected to the user's computer. In this prior art process, the user defines the test traffic by selecting the protocol(s) (e.g., IPv4, IPv6, Frame Relay, ATM) and pairing endpoints. With the protocol and endpoint pairs selected, the process typically next involves the user selecting the frame size and packet rate of each traffic item.
Conceptually, generating test traffic is a simple matter: the user defines the test traffic and then the specialized hardware transmits the traffic. When the amount of traffic to be transmitted is small it can be a simple task. However, in practice this is tremendously complex.
Generating test traffic that realistically simulates a real world environment requires a complex mix of traffic, with ebbs and flows, errors, bursts, etc. The simulation may include hundreds of source and destination endpoints. A testing of carrier-class equipment may involve generating millions or even billions of packets. These packets must be created and transmitted quickly enough that the result looks realistic—for example, like the behavior of an entire large city. For small tests, it may be sufficient to create all of the packets and store them in memory, and then transmit them according to the user's definition. For larger tests, this is practically impossible.
In one prior art traffic generation system, the user is provided with a limited facility for grouping flows of only VLAN test traffic having the same, single source endpoint or the same, single protocol, and nothing else. Furthermore, if any field of the group was to be modified, the prior art system required redoing the selection of protocols, endpoint pairs, frame size and packet rate. It was considered impossible to do anything more because of the complexity and resource requirements of anything but very small tests.
To generate huge volumes of test traffic quickly enough, one prior art solution has been to optimize the specialized hardware specific to different protocols. Another solution has been to create custom data structures that efficiently describe the test traffic. According one of these latter solutions, the test traffic is described as one or more arrays. The array will have fields corresponding to the fields of the packets, plus additional fields corresponding to metadata which the traffic generation system knows about the packets. For example, for IP packets, the fields include source IP address, destination IP address and quality of service. The metadata fields include source endpoint identification and destination endpoint identification.
Having an array with these fields, though, is far from sufficient for anything but small tests. Thus, the values in the array are instead described using a shorthand (i.e., encoded) so that more information can be packed efficiently into limited memory, and the packets generated efficiently with limited processing resources. To accomplish this, software translates the user's test traffic definition into an array of the shorthand-encoded values. According to one prior art shorthand, the values can take the form of either an “array”, a “mesh”, a “nest”, a “counter” or a “limit”. Other forms may also be included. The array form is a list of single values, such as 1, 210, 44, 23. The mesh form has a shorthand-encoded value along with a “repeat” value and a “count” value. The repeat value dictates how many times to repeat the set. The count value tells how many times to repeat each member in the set before using the next member in the set. The nest form has two shorthand values, and dictates that one of the shorthand values is nested inside the other. The counter form has a start value, an increment value and a count value. The start value dictates the first value in the set, the increment dictates how to increment each member to the next, and the count value dictates the number of members in the set. The limit form has a shorthand value, a “start” value and an “end” value. With the limit form, the value is a subset of the specified shorthand value starting from the start value and continuing to the end value.
Even though using arrays of shorthand values is helpful for storing test traffic definitions and generating traffic from them, it has not alone made modifying the definitions any less difficult. Especially when dealing with large amounts of traffic (e.g., millions of packets or more), modifying a test traffic definition has been a tedious task, if at all possible.
Throughout this description, elements appearing in figures are assigned three-digit reference designators, where the most significant digit is the figure number and the two least significant digits are specific to the element. An element that is not described in conjunction with a figure may be presumed to have the same characteristics and function as a previously-described element having a reference designator with the same least significant digits.